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Abstract 

This document describes a Prefix Delegation Mechanism which 
delegates IPv6 prefixes to a subscriber's network (or "site") by an 
internet Service Provider (ISP). It uses ICMPV6 messages to handle 
prefix Delegation between the Delegating Router and the Requesting 
Router. 
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1. introduction 

With the introduction of IPv6 [IPv6], the address space for nodes has 
increased manifold. With such an increased address space several 
ISPs would be ready to provide the IPv6 access to the public, with 
such a task in mind, a requirements draft specifying Requirements 
for IPv6 Prefix Delegation [PDReq] was written. It specifies the 
requirements for an efficient mechanism to delegate prefixes from the 
ISP's site to the customer's site. It also mentions that the 
delegating mechanism should automate the process of informing the 
customer's networking equipment of the prefixes to be used at the 
customer's site. 

This document describes a mechanism to delegate prefixes from PE to 
CPE. 

2. Terminologies and Definitions 

2.1 Basic Terminologies and setup 

The following figure illustrates a likely example for the 
organization of a network providing subscription IPv6 service: 

/ \ 

/ 

/ \ / 

+ + + +/ \ / 

ISP Edge Router | Point-to-point | customer* 

+ + Router | Customer networks 

(PE) | link | (CPE) + 

+ + + +\ / \ 

\ / \ 
+ I 
\ / 
\ / 

Figure 1: Illustration of ISP-customer network architecture 
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Figure 2: Illustration of relationship between a Requesting Router 
and a Delegating Router 

PE: Provider edge device; the device connected to the service 
provider's network infrastructure at which the link to the 
customer site is terminated 

CPE: Customer premises equipment; the device at the customer site at 
which the link to the ISP is terminated 

RR: Requesting Router; the router on the customer's end which makes 
the requests to the CPE. It could also be a single machine which 
requires a prefix for it's own address. 



DR: Delegating Router; the router on the ISP's end which delegates 
the addresses to the RR. 

2.2 Mechanism Specific Terminology 

Prefix Soli citation (PS) - A message type with which a RR makes a 
request to the DR to allocate a set of prefixes for itself. 

Prefix Del egati on (PD) - A message type with which a DR delegates a 
set of prefixes to an RR. This may or may not be in response to a 
PS message. 

Arbitrary Del egati on (AD) - A type of delegation where the CPE does 
not have any particular preference over any prefix, but requires 
just an arbitrary number of prefixes at a specified prefix length. 

Block Del egati on(BD) - A type of delegation where the CPE prefers 
that its prefixes be within a specified range and with a specified 
prefix length. 

individual Del egati on (ID) - A type of delegation where the CPE 
requires a certain individual prefix at a specified length. 
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3. Alignment with Requirements 

The mechanism specified in this document intends to solve the 
requirements issues specified in [PDReq] . A summary of the 
requirements and the solutions are as below. 

3.1 Number and Length of Delegated Prefixes 
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The mechanism specified allows the CPE to request multiple prefixes 
with multiple prefix lengths for each type of prefix requested. 
It also allows the CPE to make prefix requests in different formats 
with different preferences in one single request. 

3.2 use of Delegated Prefixes in Customer Network 

in the mechanism specified, the PE does not impose any rule or 
restrictions on the creation of longer, different prefixes by 
the CPE once it has been delegated a given set of prefixes. 
It allows the CPE to form its own set of prefixes from the set 
of prefixes that were delegated to it by the PE and further 
delegate them inside the customer's network. 

3.3 Static and Dynamic Assignment 

The mechanism specified would be capable of handling both static, 
long-lived pre-assignment of addresses and dynamic, short-lived, 
on-demand assignment of prefixes to a customer. Pre-assignment of 
addresses refers to a case where the number of prefixes to be 
delegated to the Requesting Router (RR) are determined before the 
first request is made from the RR to the Delegating Router (DR) . 
An example could be a case where the CPE is assigned a set of 
prefixes after completing a process of registration over paper. 
The mechanism specified differentiates between static and dynamic 
prefixes based on the requested/assigned valid lifetimes of the 
prefixes. 

3.4 Policy-based Assignment 

The mechanism specified would allow the PE to perform policy based 
assignment of prefixes to the CPE. This policy may include decisions 
that determine the number, length and valid lifetimes that could be 
assigned to a particular CPE. Using such policies, the PE should be 
able to serve a CPE's request as requested or it could serve it as 
best as it could. 

3.5 Expression of Requirements or Preferences by the CPE 

The mechanism specified would allow the CPE to specify the various 
preferences that it has over the prefix that it requests. These 
preferences include 

- An arbitrary number of prefixes for a specified length 

- A block of contiguous prefixes within the address space, each 
such block with a certain prefix length. 

- An individual prefix that is fully specified, with a certain 
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prefix length. 

3.6 Security Mechanism 

The mechanism specified allows the CPE and the PE to use supported 
security mechanisms. For example, ICMP protocol packet exchanges can 
be authenticated using the IP Authentication Header [ipv6-auth] or IP 
Encapsulating Security Payload Header [IPv6-ESP] . 

3.7 Accounting 
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The mechanism specified would allow the PE to obtain various 
accounting information about the prefixes delegated. 

3.8 Hardware Technology Considerations 

The mechanism specified does not have any known hardware 
technological limitations and would work on any hardware technology 
between the CPE and PE. It does not post any restrictions on the 
ISP's ability to utilize any hardware technology's authentication 
mechanism, if available. 

4. Message Types 

4.1 Prefix Solicitation 

A Prefix Solicitation (PS) message is sent by the RR to the DR 
requesting for a set of prefixes that are specified in the message. 

0 12 3 

01234567890123456789012345678901 

-I — I I I I ( t I I J I I I h-H I I I I I I I I i I I * I H — H I I K 

| Type | Code | Checksum | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Sequence Number | service |D|A| Reserved | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-"+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Identifier I 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+-+-+~+-+-+-+-+-+-+-+~+-+~+ 

| Options ... 

+-+-+-+-+-+-+-+-+-+-+-+- 



IP Fields: • 

source Address 



An IP address assigned to the sending interface of 
the RR 

Destination Address 

The IP address of the dr 

Hop Limit 255 

Authentication Header 

If a Security Association for the IP Authentication 
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Header exists between the sender and the 
destination address, then the sender SHOULD include 
this header. 

ICMP Fields: 

Type PD_CPE_REQUEST 
code 0 

Checksum The ICMP checksum. See [ICMPV6] . 
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seq Num 16-bit unsigned integer. The Sequence Number for 

this request. It is generated by the RR and 
should be uniformly distributed across the 
requests, it should be a non-zero value. This 
SHOULD be used in all requests and returns 
of prefixes. The Sequence Number is used as a 
message identifier between the RR and DR and 
SHOULD not change during one transaction. 



Service 



Reserved 



8-bit unsigned integer. The Service-Band of 
the customer making this request. The RR 
MAY set it to its existing Service-Band or 
to another Service-Band that it expects itself 
to be from now on. The Service-Band signifies 
the kind of preferential service that the RR 
enjoys with the DR. 

The usages of the Service field are discussed in 
Appendix A. 

One bit "Discretion" flag. If it is set by the 
RR it indicates that the the DR is allowed to 
use it's discretion while serving this request. 
This allows the RR to express its requests 
freely, and at the same time allowing the DR 
to apply its policies depending on the RR. It 
MAY be set by the RR if it wants to allow DR to 
use its discretion in allocating addresses to 
this request. 

The usages of the Discretion flag are discussed 
in Appendix A. 

One bit "Acknowledgement" flag. If it is set, 
it means that the RR is acknowledging a reply 
from the DR. It SHOULD be set to zero in a 
request message. It SHOULD be set to one while 
acknowledging the receipt of prefixes and 
returning of prefixes. 

6-bit Reserved Field, it MUST be initialized to 
zero by the sender and MUST be ignored by the 
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receiver. 



identifier 



32-bit unsigned integer. Unique identifier for 
this RR. It SHOULD be set to zero if the RR 
does not know its identifier. A value of zero 
would mean that the DR has to allocate an 
identifer for this RR. Once the RR has been 
alloted its Identifier, it MUST use it in all 
its future communications. The Identifier could 
be a pre-assigned Identifier given by the DR. 



Possible options: 
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Arbitrary Delegation Prefix Options 

Arbitrary Delegation Prefix options can be 
specified. The RR could require 'm' sets of 
'n' prefixes with 'x f bits in prefix length, 
where a set is defined as {number of prefixes, 
prefix length} 



Block Delegation Prefix Options 

Block Delegation Prefix options can be 
specified. The RR could require 'm' sets of 
'n' prefixes which lie within a certain block 
of addresses and are 'x' bits in prefix length, 
where a set is defined as {number of prefixes, 
prefix length} 



individual Delegation Prefix Options 

individual Delegation Prefix options can be 
specified. The RR could require 'm' sets of 
prefixes which have "y 1 as prefix, where a set 
is defined as {prefix, prefix length} 

Source Link Layer Address 

The Source Link Layer Address option MUST be 
specified in cases when the RR requests a new 
identifier. It MUST not be specified when the 
RR knows its Identifier. 



4.2 Prefix Delegation 

A Prefix Delegation (PD) message is sent by the DR to the RR 
delegating a set of prefixes that are specified in the message. 
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0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Code | checksum | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Seq Num | Service |A| Reserved | 

| Identifier I 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Options ... 
+-+-+-+-+-+-+-+-+-+-+-+- 

IP Fields: 

Source Address 
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An IP address assigned to the sending interface 
of the DR. 

Destination Address 

The source IP address of the packet that sent the 
request with the current sequence number. 



Hop Limit 



255 



Authentication Header 

If a Security Association for the IP Authentication 
Header exists between the sender and the 
destination address, then the sender SHOULD include 
this header. 



ICMP Fields: 
Type 
Code 

Checksum 
Seq Num 



Service 



PD_PE_RESPONSE 



The ICMP Checksum. See [ICMPv6] . 

16-bit unsigned integer. The Sequence Number for 
this request. It is the same Sequence Number of 
the PS message that generated this response. 
It SHOULD be a non-zero value. This should be 
used in all responses. 

8-bit unsigned integer. The Service-Band 
assigned to the customer making this request. 
The DR sets it to its existing Service-Band for 
the RR. The Service-Band signifies the kind of 
preferential service that the RR enjoys with 
the DR. 

1-bit Acknowledgement Flag. It SHOULD be set to 
1 when the DR is acknowledging a request from 
the RR. It SHOULD be set to zero when the DR 
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is sending a message on it's own. 

7-bit Reserved field. SHOULD be set to zero by 
the DR and should be ignored by the RR. 

32-bit Identifier field, created by the DR 
using the RR's interface identifier. Uniquely 
identifies a RR. The way in which the DR 
generates the Identifier is implementation 
dependent. 



Possible options: 



Block Delegation Prefix Options 



Block Delegation Prefix options can be 
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specified. The DR could delegate 'm' sets of 
'n' prefixes which lie within a certain block 
of addresses and are 'x' bits in prefix length, 
where a set is defined as {number of prefixes, 
prefix length} 

individual Delegation Prefix Options 

individual Delegation Prefix options can be 
specified. The DR could delegate 'm' sets of 
prefixes which have 'y' as prefix, where a set 
is defined as {number of prefixes, 
prefix length}. 

4.3 Option Formats 

Prefix Delegation messages include zero or more options, some of 
which may appear multiple times in the same message. All options are 
of the form: 

0 12 3 

01234567890123456789012345678901 

j Type I Length | ... I 

+-+-+-+-+-+-4--+-+-+-+-+-+-+-+-+-+-+--f-+-*+-+--f-+-+-+-+-+-+--»--+--f-+ 

■ i **** 



Fields: 

Type 8-bit identifier of the type of option. The 

options defined in this document are: 

Option Name Type 

source Link-Layer Address 1 
Arbitrary Delegation Request Option 2 
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Block Delegation Request Option 3 

individual Delegation Request Option 4 

individual Delegation Response Option 5 

Block Delegation Response Option 6 

4.3.1. source Link-layer Address Option 

0 1 2 3 



01234567890123456789012345678 9 0 1 
| Type | Length I Link-Layer Address ... 

Fields: 
Type 

1 for Source Link-layer Address 



Length The length of the option (including the type and 
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length fields) in units of 8 octets. For example, 
the length for IEEE 802 addresses is 1 [IPv6- 
ETHER] . 

Link-Layer Address 

The variable length link-layer address. 
The content and format of this field (including 
byte and bit ordering) is expected to be specified 
in specific documents that describe how IPv6 
operates over different link layers. For instance, 

[IPV6-ETHER] . 

Description 

The Source Link-Layer Address option contains the 
link-layer address of the sender of the packet, it 
is used in the Prefix Request messages when the RR 
does not know its unique identifier. 

These options MUST be silently ignored for other 
messages. 

4.3.2. Arbitrary Delegation Request Option 

0 12 3 

01234567890123456789012345678901 

+ -+-+-+- + -+- + - + - + - + -+-+- + - + -+-+- + - + -+-+-+-+-+-- H— I— +-+-+- + -+- + - + - + 

I Type | Length | Prefix Length |No.of Prefixes | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
+ Reserved I 

+-+-+-+-+-+-+-+— f -+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I valid Lifetime 1 I 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--*--+-+-+ 
I Valid Lifetime 2 | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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2 for Arbitrary Delegation Request Option 
2 

8-bit unsigned integer. The length of the 
requested prefix. The value ranges from 0 to 128. 
It denotes the length of the all the prefixes 
that would be delegated as a response to this 
message. A value of 0 notifies the DR to use it's 
default prefix length. 



No. of Prefixes 



Reserved 



8-bit unsigned integer. The number of prefixes 
requested by the RR in this message. 

32-bit unused field. It MUST be initialized to zero 
by the sender and MUST be ignored by the receiver. 



Valid Lifetime 1 



32-bit unsigned integer. The length of time in 
Page 11 
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seconds (relative to the time the ack is received) 
that the RR expects the associated prefix(es) to 
be valid, ie, the time in seconds until which the 
RR expects the DR to route packets, which have 
(one of) the associated prefix(es) in the 
destination address, to the RR. 

A value of all zero bits (0x00000000) set in a 
request message by the RR represents that it has 
no preference about the lifetime of the prefix(es). 

A value of all 1 bits (Oxffffffff) set in a 
Arbitrary Delegation Request Message by the RR 
is invalid. It SHOULD NOT be set by the sender and 
SHOULD be silently ignored by the receiver. 

valid Lifetime 2 

32-bit unsigned integer. The length of time in 
seconds (relative to the time the ack is received) 
that the RR expects the associated prefix(es) to 
be valid, ie, the time in seconds until which the 
RR expects the DR to route packets, which have 
(one of) the associated prefix(es) in the 
destination address, to the RR. 

A value of all zero bits (0x00000000) set in a 
request message by the RR represents that it has 
no preference about the lifetime of the prefix(es). 

valid Lifetime 2 SHOULD be set to a value lesser 
than valid Lifetime 1. 

valid Lifetime 2 SHOULD be set to zero by the 
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sender and ignored by the receiver if Valid 
Lifetime 1 is all -zero. 

A value of all 1 bits (Oxffffffff) set in a 
Arbitrary Delegation Request Message by the RR is 
invalid. It SHOULD NOT be set by the sender and 
SHOULD be silently ignored by the receiver. 

Description 

The RR can use the Arbitrary Delegation Request 
Option to request for an arbitrary number of 
prefixes which have an specified prefix length. 
It can specify two values as expected valid 
lifetimes for the DR to choose from. If the RR 
is not specific about lifetimes, it SHOULD set 
both the fields to zero. 

A value for infinite valid lifetime is disallowed. 

The Arbitrary Delegation Request option appears in 
a PD_CPE_REQUEST message. These options must be 
silently ignored for other messages. 

4.3.3. Block Delegation Request Option 
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0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Prefix Length |No. of Prefixes | 

+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Reserved I 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| valid Lifetime 1 I 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+■-+-+-+-+-+-+-+-+-+ 
| valid Lifetime 2 I 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

I I 
+ + 

I I 
+ Prefix Address Blockl + 

I I 
+ + 

I I 

-h-H I I I h-H I I H-H--H I I I I I h-H I I I i I I t I I I I I h--h 

I I 
+ + 
I I 

+ Prefix Address Block2 + 

I I 
+ + 

I I 

H — I I I I t I I I — I I I I I I I I I — J I I k— H I I K— H — I I I I I I- 



Fields: 
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3 for Block Delegation Request Option 



Length 

Prefix Length 



8-bit unsigned integer. The length of the 
requested prefix. The value ranges from 0 to 128. 
It denotes the length of the all the prefixes 
that would be delegated as a response to this 
message. A value of 0 notifies the DR to use it's 
default prefix length. 



No. of Prefixes 



Reserved 



8-bit unsigned integer. The number of prefixes 
requested by the RR in this message. 

32-bit unused field. It MUST be initialized to zero 
by the sender and MUST be ignored by the receiver. 



valid Lifetime 1 



32-bit unsigned integer. The length of time in 
seconds (relative to the time the ack is received) 
that the RR expects the associated prefix(es) to 
be valid, ie, the time in seconds until which the 
RR expects the DR to route packets, which have 
(one of) the associated prefix(es) in the 
destination address, to the RR. 
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A value of all zero bits (0x00000000) set in a 
request message by the RR represents that it has 
no preference about the lifetime of the prefix(es) 

A value of all one bits (Oxffffffff) set in a 
ack-request message by the RR represents that it 
is returning the address. 

valid Lifetime 2 

32-bit unsigned integer. The length of time in 
seconds (relative to the time the ack is received) 
that the RR expects the associated prefix(es) to 
be valid, ie, the time in seconds until which the 
RR expects the DR to route packets, which have 
(one of) the associated prefix(es) in the 
destination address, to the RR. 

A value of all zero bits (0x00000000) set in a 
request message by the RR represents that it has 
no preference about the lifetime of the prefix(es) 

valid Lifetime 2 SHOULD be set to a value lesser 
than Valid Lifetime 1. 

Valid Lifetime 2 SHOULD be set to zero by the 
sender and ignored by the receiver if valid 
Lifetime 1 is all -zero or all -one. 
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A value of all ones (Oxffffffff) SHOULD NOT be 
set in valid Lifetime 2 by the sender and SHOULD 
be ignored by the receiver. 

Prefix Address Block 1 

128-bit field. The start of an address block 
(inclusive) in the IPv6 address space from where 
the RR wants its prefix(es). The Prefix Lenqth 
field contains the number of valid leading bits in 
the prefix address block. The bits in the prefix 
address block after the prefix length are reserved 
and MUST be initialized to zero by the sender and 
ignored by the receiver. An RR SHOULD send a 
prefix option only for globally valid prefixes 
and a DR SHOULD ignore any other prefix option. 

Prefix Address Block 2 

128-bit field. The end of an address block 
(inclusive) in the IPv6 address space from where 
the RR wants its prefix(es). The Prefix Length 
field contains the number of valid leading bits in 
the prefix address block. The bits in the prefix 
address block after the prefix length are reserved 
and MUST be initialized to zero by the sender and 
ignored by the receiver. An RR SHOULD send a 
prefix option only for globally valid prefixes 
and a DR SHOULD ignore any other prefix option. 
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The RR can use the Block Delegation Request Option 
to request for an fixed number of prefixes which 
have an specified prefix length that lie within a 
block of addresses. 

It can specify two values as expected valid 
lifetimes for the DR to choose from. If the RR 
is not specific about lifetimes, it can set BOTH 
the fields to zero. 

A value for infinite valid lifetime MUST be 
disallowed. 

The Block Delegation Request option appears in a 
PD_CPE_REQUEST message. These options MUST be 
silently ignored for other messages. 
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4.3.4. individual Prefix Delegation Request Option 
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0 12 3 

01234567890123456789012345678901 

| Type | Length | Prefix Length | Reservedl | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Reserved2 I 

+-+-+-+-+~+-+-+~+-+-+-+-+~+-+-+-+-+-+-+~+~+~+-+-+-+-+-+-+-+-+-+-+ 
I valid Lifetime 1 I 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Valid Lifetime 2 I 

+-+-+-+-+-+-+-+-+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+ 

I I 
+ + 

i i 

+ Prefix + 

I I 
+ + 

I I 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Fields: 

Type 4 for Individual Prefix information 



Length 4 

Prefix Length 8-bit unsigned integer. The number of leading bits 
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in the Prefix that are valid. The value ranges 
from 0 to 128. It denotes the length of the all 
the prefixes included in this message. A value of 
0 notifies the DR to use its default prefix length. 

Reservedl 6-bit unused field. It MUST be initialized to zero 

by the sender and MUST be ignored by the receiver. 

Reserved2 32-bit unused field. It MUST be initialized to zero 

by the sender and MUST be ignored by the receiver. 

valid Lifetime 1 

32-bit unsigned integer. The length of time in 
seconds (relative to the time the ack is received) 
that the RR expects the associated prefix to 
be valid, ie, the time in seconds until which the 
rr expects the DR to route packets, which have 
the associated prefix in the destination address, 
to the RR. 

A value of all zero bits (0x00000000) set in a 
request message by the RR represents that it has 
no preference about the lifetime of the prefix. 

A value of all one bits (Oxffffffff) set in a 
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ack- request message by the RR represents that it 
is returning the address. 

Valid Lifetime 2 

32-bit unsigned integer. The length of time in 
seconds (relative to the time the ack is received) 
that the RR expects the associated prefix to be 
valid, ie, the time in seconds until which the RR 
expects the DR to route packets, which have the 
associated prefix in the destination address, to 
the RR. 

A value of all zero bits (0x00000000) set in a 
request message by the RR represents that it has 
no preference about the lifetime of the prefix. 

valid Lifetime 2 SHOULD be set to a value lesser 
than Valid Lifetime 1. 

valid Lifetime 2 SHOULD be set to zero by the 
sender and ignored by the receiver if valid 
Lifetime 1 is all -zero or all -one. 

A value of all ones (Oxffffffff) SHOULD NOT be 
set in valid Lifetime 2 by the sender and SHOULD 
be ignored by the receiver. 

Prefix An IP address or a prefix of an IP address. The 

Prefix Length field contains the number of valid 
leading bits in the prefix. The bits in the prefix 
after the prefix length are reserved and MUST be 
initialized to zero by the sender and ignored by 
Page 16 
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the receiver. A RR SHOULD send a prefix option 
only for globally valid prefixes and a DR SHOULD 
ignore any other prefix option. 



Description 

The individual Request Prefix option lets the RR 
request for multiple prefixes in one single 
message. It also allows the RR to return or return 
one or more prefixes. 

The Individual Request Prefix option appears in a 
pd_cpe_request message. These options must be 
silently ignored for other messages. 
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4.3.5. Block Delegation Response Option 

0 12 3 

01234567890123456789012345678 9. 0 1 
-i — i — i — i — i — i — i — i — i — i — i — i — i — i — i — t — i — i — i — i — i — i- — i — i — i — i — i — i — i — i — i — i — i- 
| Type | Length | Prefix Length | Reserved | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Valid Lifetime I 

H I » I I • I I I I I I I I I t I I I I I I I H-H I I I I I I h--h 

I I 

■f + 

I I 

+ Prefix Address Blockl + 

I I 
+ + 

I I 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

I I 
+ + 

■f Prefix Address Block2 + 

I I 
+ + 

I I 
Fields: 

Type 6 for Block Delegation Response Option 

Length 5 
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Prefix Length 8-bit unsigned integer. The length of the 

delegated prefix. The value ranges from 1 to 128. 
it denotes the length of the all the prefixes 
that are delegated as a response to this message. 

Reserved 32-bit unused field. It MUST be initialized to zero 

by the sender and MUST be ignored by the receiver. 

valid Lifetime 

32-bit unsigned integer. The length of time in 
seconds (relative to the time the ack is received) 
that the associated prefix is valid, ie, the time 
in seconds until which the DR would route packets, 
which have the associated prefix in the destination 
address, to the RR. 

A value of all one bits (Oxffffffff) set in a 
response message by the DR represents that it is 
revoking the address. 
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Prefix Address Block 1 

128-bit field. The start of an address block 
(inclusive) in the IPv6 address space from where 
the DR delegates its prefix(es). The Prefix Length 
field contains the number of valid leading bits in 
the prefix address block. The bits in the prefix 
address block after the prefix length are reserved 
and MUST be initialized to zero by the sender and 
ignored by the receiver. An DR SHOULD delegate the 
prefix option only for globally valid prefixes 
and a RR SHOULD ignore any other prefix option. 

Prefix Address Block 2 

128-bit field. The end of an address block 
(inclusive) in the IPv6 address space from where 
the DR delegates its prefix(es). The Prefix Length 
field contains the number of valid leading bits in 
the prefix address block. The bits in the prefix 
address block after the prefix length are reserved 
and MUST be initialized to zero by the sender and 
ignored by the receiver. An DR SHOULD delegate the 
prefix option only for globally valid prefixes 
and a RR SHOULD ignore any other prefix option. 

Description 

The DR can use the Block Delegation Response 
option to delegate a fixed number of prefixes 
which have an arbitrary prefix length that lie 
within a block of addresses. 

A value for infinite valid lifetime is disallowed. 

The Block Delegation Response option appears in a 
PD_PE_RESPONSE message and PD_CPE_REQUEST message. 
These options MUST be silently ignored for other 
messages. 
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4.3.6. individual Prefix Delegation Response Option 



0 12 3 

01234567890123456789012345678901 
+-+-+-+-+~+-+-+-+-+-+~+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+-+-+-+-+-+-+ 
| Type | Length | Prefix Length | Reserved | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
j valid Lifetime I 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

I I 
+ | 

+ Prefix + 

I I 
+ + 

I I 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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Fields: 
Type 



5 for individual Prefix Information 



Length 

Prefix Length 



Reserved 



8-bit unsigned integer. The number of leading bits 
in the Prefix that are valid. The value ranges 
from 1 to 128. It denotes the length of the all 
the prefixes included in this message. 

6-bit unused field. It MUST be initialized to zero 
by the sender and MUST be ignored by the receiver. 



Valid Lifetime 



Prefix 



32-bit unsigned integer. The length of time in 
seconds (relative to the time the ack is received) 
that the associated prefix is valid, ie, the time 
in seconds until which the DR would route packets, 
which have the associated prefix in the destination 
address, to the RR. 

A value of all one bits (Oxffffffff) set in a 
response message by the DR represents that it is 
revoking the address. 

An IP address or a prefix of an IP address. The 
Prefix Length field contains the number of valid 
leading bits in the prefix. The bits in the prefix 
after the prefix length are reserved and MUST be 
initialized to zero by the sender and ignored by 
the receiver. A DR SHOULD NOT send a prefix 
option only for globally valid prefixes and a RR 
SHOULD ignore any other prefix option. 



Description 
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The individual Prefix option lets the 
dr delegate multiple prefixes to the rr in one 
single message. It also allows the DR to cancel 
or revoke one or more prefixes. 

The Block Delegation Response option appears in a 
pd_pe_response message and pd_cpe_request message. 
These options MUST be silently ignored for other 
messages. 



5. Prefix Delegation Mechanism and Overview 
5.1 Conceptual Data Structures 

DRs will need to maintain the following information 
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Free Prefix cache 

The Free prefix cache would contain the list of available 
prefixes. For each of the free prefix, the DR can have a 
minimum and a maximum valid lifetime that it can delegate 
it for. This would facilitate the DR to allocate set of 
addresses for dynamic assignments, static assignments and 
maintain band of such address pools. It should also contain 
details of acceptable IP addresses for this prefix, last 
allocated RR's identifier, IP address and state of the prefix. 
Having the IP address of the RR would also help in handling 
cases of pre-assigned prefixes. 

Allocated Prefix Cache 

The Allocated prefix cache would contain the list of 
allocated prefixes. For each of the allocated prefixes, the 
DR can have the request id for this prefix, the identifier 
of the RR that has been delegated this prefix, the valid 
lifetime of the prefix and a timer that would clear the 
prefix from the Allocated prefix cache and return it back 
to the Free prefix cache. 

RRs will need to maintain the following information 

Current Prefix Cache 

The Current prefix cache would contain the list of all the 
prefixes that are either requested for or already delegated 
to the RR, Valid Lifetime(s) for the prefix, state of the 
prefix. 

Note that the above conceptual data structures can be implemented 
using a variety of techniques. One possible implementation is to use 
a single table for all of the above data structures. 

Regardless of the specific implementation, it is critical that the 
data be easily accessible and persistent to avoid any issues that 
could result due to failures and crashes on the nodes. An 
implementation is at liberty to implement such data structures in any 
way it pleases. 

5.2 States of Prefixes 
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A Prefix is said to be in one of the following states at any time 
in the DR's Data Structures. 

Free The Prefix is available for delegation provided 

the RR meets other requirements if any. 

Pending The Prefix has been delegated to a RR and is 

awaiting a acknowledgement from the RR. 

Delegated The Prefix has been delegated to a RR and the 

RR has acknowledged the receipt of this prefix. 

Deprecated The Prefix has been delegated to and 



Arun & shankar 
internet-Draft 



Expires October 30, 2004 [Page 21] 

IPv6 Prefix Delegation using ICMPv6 April 2004 



acknowledged by the RR and is due to expire in 
a specified time (ideally, PDDeprecateTimer) . 

Expired The Prefix has been delegated to and 

acknowledged by the RR and the valid lifetime 
has expired. 

A Prefix is said to be in one of the following states at any time 
in the RR's Data structures. 



Pending The Prefix has been sent as a request to the DR 

and is awaiting a response from the RR. 

Delegated The Prefix has been delegated to by the DR and 

an acknowledgement to the receipt of this 
prefix has been sent. 

Deprecated The Prefix has been delegated by and an 

acknowledgement sent to the DR and is due to 
expire in a specified time (ideally, 
PDDeprecateTimer) . 

Expired The Prefix has been delegated by and an 

acknowledgement sent to the RR and the valid 
lifetime has expired. 

5.3 Conceptual Sending Algorithm 

A Requesting Router(RR) sends a Prefix Solicitation(PS) message to 
a Delegating Router (DR) when it finds the needs for delegating 
prefixes downstream inside the customer environment. It includes all 
the prefixes that it requires in the PS message using the various 
options available, viz. Arbitrary Delegation (AD) , Block 
Delegation(BD) and individual De legation (ID) . If a RR has arranged 
for pre-assigned prefixes, it would send an empty message to the DR 
to let it know that he is online and can respond to Response queries 
with acknowledgements. 

A DR receives a PS message from a RR and looks up for availability 
of prefixes. It sends a list of all the available prefixes that 
suit the RR's requirements, after considering multiple factors like 
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Discretionary setting and the Service-Band of the RR. After sending 
a reply to the PS using a Prefix Del egati on (PD) message, the DR 
awaits an acknowledgement from the RR to the effect. Only after the 
acknowledgement from the RR, can the DR start its billing for the 
delegated prefixes and forwarding of the packets received, if it 
receives an empty request message, it checks it's data structures to 
see if there are preassigned prefixes for this RR, and if so, 
responds with the preassigned prefixes. 

The RR receives the PD message sent by the DR and checks the 
prefixes that it has been delegated. It then prepares a PS message 
with the ack field set and sends it to the DR acknowl edging the 
receipt of the prefixes. The RR can also return prefixes that have 
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been given to it by the DR. 

when the valid lifetime is about to expire for a given prefix, the 
RR may choose to renew it with the DR. It sends a PS message to the 
DR indicating the newer lifetimes that it requires for the given 
prefixes. 

when the valid lifetime is about to expire for a given prefix, the 
DR does not send reminder probes to the RR to that effect. It is the 
responsibility of the RR to renew a prefix on the event of it 
expiring. 

The DR can choose to revoke a set of prefixes that were previously 
delegated to a RR before they expire. The RR sends a PD message with 
the list of prefixes that are to be revoked. In such an instance, the 
DR need not wait for acknowledgement. For example, a DR might choose 
to revoke a prefix due to complaints of abuse of a certain prefix. 

The RR can attempt to regain the prefixes by sending a PS message 
containing the revoked prefixes. 



6. Requesting Router Specification 

A Requesting Router(RR) would be able to send Prefix Solicitation(PS) 
messages and acknowledged PS messages to a Delegating Router(DR). 

6.1 Prefix Solicitation by a Requesting Router 

A Requesting Router (RR) finds the need for delegating prefixes 
downstream and sends a Prefix Solicitation(PS) message to the 
Delegating Router (DR). 

6.1.1 Prefix Solicitation Header Specification 

- rr sets the Type to PD_CPE_REQUEST, Code to zero and the 
ICMP checksum as mentioned in [ICMPV6] . 

- if the RR chooses to allow the DR to use its "discretion" in 
delegating the prefixes, it sets the Discretion bit to one. 
Otherwise, it is set to zero. 

- in a Prefix Solicitation message, the Acknowledgement bit SHOULD 
be set to zero by the RR. 

- The RR SHOULD be capable of generating a 16-bit long sequence 
number. This number should be randomized using a seed and SHOULD 
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be different than any recently generated sequence number on this 
node. This sequence number SHOULD be set in the Sequence Number 
field. The node can choose to implement the sequence number 
generating algorithm in a way that it chooses to be appropriate. 

- If the RR does not have an agreed service type and is requesting 
the DR for any service type, it sets the Service Type field to 
zero, if the RR already has an agreed service type, it SHOULD set 
it in the Service Type field. If the RR wants to chanqe its agreed 
service type, it SHOULD set the new service type in the Service 
Type field. 

- If the RR does not have a unique identifier to identify itself 
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with the DR, it SHOULD set the Identifier field to zero and 
it SHOULD include the Source Link Layer Address(SLLA) Option. If 
the RR has an already agreed identifier to identify itself with 
the DR, it SHOULD set the Identifier field accordingly. 

- The Reserved field should be initialized to zero. 

6.1.2 Prefix solicitation Option Specification 

- It includes all the prefixes that it requires in the PS message 
using the various options available, viz. Arbitrary Del egati on (AD) , 
Block Del egati on (bd; and individual Del egati on (ID) . 

- If the prefixes are preassigned, no options are included. 

- If the RR requires a prefix with no particular preference, it 
adds an AD Request Option to the PS message. 

The expected length that the prefixes need to have is set in the 
Prefix Length field. If there is no preference, it is set to zero. 
The number of arbitrary prefixes with the aforesaid prefix length 
is set in the no. of Prefixes field. 

The number of seconds the prefix is expected to be alive is set in 
the Valid Lifetime 1 field, if the RR has no preference in this 
regard, the valid Lifetime 1 field is set to zero. 
The number of seconds the prefix is expected to be alive is set in 
the Valid Lifetime 2 field. If the RR has no preference in this 
regard, the valid Lifetime 2 field is set to zero. The Valid 
Lifetime 2 field SHOULD be set to a value lesser than the value 
specified in Valid Lifetime 1 field. 

- If the RR requires a prefix to lie within a particular block of 
addresses, it adds a BD Request Option to the PS message. 

The expected length that the prefixes need to have is set in the 
prefix Length field. If there is no preference, it is set to zero. 
The number of prefixes with the aforesaid prefix length is set in 
the No. of Prefixes field, if it is set to zero, all prefixes 
within the block need to be delegated. 
The Reserved field should be set to zero. 

The number of seconds the prefix is expected to be alive is set in 
the valid Lifetime 1 field, if the RR has no preference in this 
regard, the Valid Lifetime 1 field is set to zero. 
The number of seconds the prefix is expected to be alive is set in 
the Valid Lifetime 2 field. If the RR has no preference in this 
regard, the Valid Lifetime 2 field is set to zero. The Valid 
Lifetime 2 field SHOULD be set to a value lesser than the value 
specified in valid Lifetime 1 field. 

The starting point (inclusive) of the address block within which 
the RR expects the prefixes to be is set in Prefix Address Block 1. 
The ending point(inclusive) of the address block within which the 
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RR expects the prefixes to be is set in Prefix Address Block 2. 

- if the RR requires a specified prefix, it adds an ID Request 
Option to the PS message. 

The expected length that the prefixes need to have is set in the 
Prefix Length field, if there is no preference, it is set to zero. 
The Reserved fields should be set to zero. 

The number of seconds the prefix is expected to be alive is set in 
the valid Lifetime 1 field, if the RR has no preference in this 
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regard, the valid Lifetime 1 field is set to zero. 
The number of seconds the prefix is expected to be alive is set in 
the valid Lifetime 2 field. If the RR has no preference in this 
regard, the valid Lifetime 2 field is set to zero. The valid 
Lifetime 2 field SHOULD be set to a value lesser than the value 
specified in Valid Lifetime 1 field. 

The specific prefix that the RR requires is set in the Prefix 
field. 



6.2 Prefix Delegation Acknowledgement & Returning by a Requesting Router 

when a DR delegates prefixes, the RR should acknowledge the receipt 
of the prefixes. The DR would start forwarding packets only after 
it receives the acknowledgement from the RR. The RR can acknowledge 
the receipt of the prefixes and also return any of the delegated 
prefixes using the same Block and individual Delegation 
Response options received in the DR's response. 

A Return could be done as a separate messaqe or it could be 
piggy-backed with an acknowledgement. If the Returning is done in 
a separate message, it would require a new sequence number. If the 
RR intends to use all the prefixes that have been allocated, it 
SHOULD send a acknowledgement message without options. If it intends 
to reject a few prefixes, they SHOULD be included as options with 
all ones (Oxffffffff) as Valid Lifetime. 

6.2.1 Prefix Delegation Acknowledgement Header Specification 

- it sets the Type to pd_cpe_request, code to zero and the 
ICMP Checksum as mentioned in [ICMPv6] . 

- The discretion bit SHOULD be set to zero. 

- in an Acknowledgement message, the Acknowledgement bit SHOULD 
be set to one by the RR. 

- The RR SHOULD use the same sequence number that was used in the 
original PS message. 

- The RR SHOULD use the same Service Type field of the PD message 
to set the Service Type field 

- The RR SHOULD use the agreed identifier to set the Identifier 
field. 

- The Reserved field should be initialized to zero. 

6.2.2 Prefix Delegation Acknowledgement Option Specification 

- Block Delegation Response Option from the PD that is acknowledged 
is included on return of prefixes, if the RR chooses to return any 
prefix the valid lifetime field is set to all ones (Oxffffffff) 

to indicate that this block of prefixes is returned. 
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- individual Delegation Response Option from the PD that is 
acknowledged is included on return of prefixes. If the RR chooses 
to return any prefix the valid lifetime field is set to all ones 
(Oxffffffff) to indicate that the individual prefix is returned. 

6.3 Prefix Renewal by a Requesting Router 
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- when a prefix reaches Deprecated state, a RR could send renewal 
messages to DR to extend the Valid Lifetime of the prefix, it 
could do so using a PS message. The renewal message is treated 
as a new solicitation message. 

After sending a PS message, the state of the prefix would be 
Pending. 

6.3.1 Prefix Solicitation Header Specification 

- It sets the Type to PD_CPE_REQUEST, code to zero and the 
ICMP Checksum as mentioned in [ICMPV6] . 

- If the RR chooses to allow the DR to use its "discretion" in 
delegating the prefixes, it sets the Discretion bit to one. 
Otherwise, it is set to zero. 

- in a Prefix Solicitation message, the Acknowledgement bit SHOULD 
be set to zero by the RR. 

- The RR SHOULD be capable of generating a 16-bit long sequence 
number. This number should be randomised using a seed and SHOULD 
be different than any recently generated sequence number on this 
node. This sequence number SHOULD be set in the Sequence Number 
field. The node can choose to implement the sequence number 
generating algorithm in a way that it chooses to be appropriate. 

- If the RR does not have an agreed service type and is requesting 
the DR for ANY service type, it sets the Service Type field to 
zero. If the RR already has an agreed service type, it SHOULD set 
it in the Service Type field, if the RR wants to change its agreed 
service type, it SHOULD set the new service type in the Service 
Type field. 

- The RR's unique identifier should be used to set the Identifier 
field. 

- The Reserved field should be initialized to zero. 

6.3.2 Prefix Solicitation Option Specification 

- It includes all the prefixes that it requires to be renewed in the 
PS message using Block Delegation(BD) and individual 
Delegation (id) . Arbitrary Delegation cannot be used since 

only well -specified prefixes can be renewed. 

- If the RR requires a block of continuos prefixes to be renewed, it 
adds a BD Request Option to the PS message. 

The length of the prefixes is set in the Prefix Length field. 

The number of block prefixes which are to be renewed is set in the 

No. of Prefixes field, if it is set to zero, all the prefixes 

within the block need to be renewed. 

The Reserved field should be set to zero. 

The number of seconds the prefix is expected to be renewed is set 
in the valid Lifetime 1 field. If the RR has no preference in this 
regard, the valid Lifetime 1 field is set to zero. 
The number of seconds the prefix is expected to be renewed is set 
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in the Valid Lifetime 2 field, if the RR has no preference in this 
regard, the valid Lifetime 2 field is set to zero. The valid 
Lifetime 2 field SHOULD be set to a value lesser than the value 
specified in valid Lifetime 1 field. 

The starting point (inclusive) of the address block within which 
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the prefixes are is set in Prefix Address Block 1. 

The ending point(inclusinve) of the address block within which the 

the prefixes are is set in Prefix Address Block 2. 

- if the RR requires to renew a specified prefix, it adds an ID 
Request Option to the PS message. 

The length of the renewing prefix is set in the Prefix Length 
field. 

The Reserved fields should be set to zero. 

The number of seconds the prefix is expected to be renewed is set 
in the Valid Lifetime 1 field, if the RR has no preference in this 
regard, the valid Lifetime 1 field is set to zero. 
The number of seconds the prefix is expected to be renewed is set 
in the Valid Lifetime 2 field, if the RR has no preference in this 
regard, the Valid Lifetime 2 field is set to zero. The valid 
Lifetime 2 field SHOULD be set to a value lesser than the value 
specified in Valid Lifetime 1 field. 

Tne specific prefix that the RR requires is set in the Prefix 
field. 

6.4 Prefix Delegation Message Validation by Requesting Router 

A RR receives Prefix Delegation(PD) messages from the DR in response 
to it's PS message. 

6.4.1 Prefix Delegation Header Validation 

- verify if Type is pd_pe_response, Code is zero and iCMPv6 checksum 
field is correct. If not, silently ignore the message. 

- if ACK field is set, ensure a solicited message with the 
corresponding sequence Number is available in the Data Structures 
with prefix state Pending. 

If ACK field is not set, ensure a solicited message with the 
corresponding sequence Number is available in the Data Structures 
with prefix state anything other than Pending, if not, silently 
ignore the message. 

- if the Sequence Number field is zero, it denotes a case of 
pre-assignment of prefixes, otherwise, check if prefixes with 
Pending state match the Sequence Number. If they do not match, 
silently ignore the message. 

- Set service field in the data structure to Service field in the 
PD header. This would be the new service band for the RR. 

- If the Identifier field is zero, the message should be silently 
ignored. If the Identifier value in the local data structure is 
zero, set the value in the Identifier field of the message. This 
SHOULD be used in all future communications. Otherwise, it should 
be checked and if it does not match, the message should be silently 
ignored. 

- The Reserved field should be ignored. 

6.4.2 Prefix Delegation Option validation 
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- If the Discretion flag was set, process each option individually. 

- if the options are empty, check if there are any preassigned 
prefixes awaiting acknowledgement for this RR. If not, silently 
ignore the message. 

- If a prefix is not in Pending state, Return the prefix. 

- Move the prefixes from the Pending state to Delegated State 

- If the Valid Lifetimes are all-zeroes, ignore the prefix 

6.5 Configurable Parameters for Requesting Router 



PDCPEMaxRetries The number of retries the RR has to perform 

before it gets a reply to its solicitation. 

PDCPEMaxPrefixes Maximum number of prefixes that could be 

requested by a RR at its next request. It 
depends on the type of service that the RR 
enjoys. 

PDCPEDynamicThreshold 

The threshold value which is used to determine 
if a prefix is static or a dynamic prefix. This 
can be used when the RR wishes to request for 
static or a dynamic prefix. 

PDCPEDeprecateTimer The value in seconds for which a prefix would 

remain deprecated, when there are 
PDCPEDeprecateTimer seconds for the Valid 
Lifetime to expire, the RR can start sending 
renewal requests for the prefix. 

PDCPERetransTimer The value in seconds between two retries. 

PDCPEReplayTimer The value in seconds after a which a RR allows 

an old sequence number to be accepted as a valid 
sequence number and not reject it as a replay. 



7. Delegating Router specification 

A Delegating Router(DR) would send Prefix Del egati on (PD) messages 
to a Requesting Router (RR). 

7.1 Prefix Delegation by a Delegating Router 

A Delegating Router(DR) responds to a Prefix Soli citation (PS) message 
from a RR with a PD message. 

7.1.1 Prefix Delegation Header Specification 

- If the Discretion bit was not set, and all prefixes with requested 
valid lifetimes are not available, silently ignore the message. 

- Set Type to PD_PE_RESPONSE, Code to zero and checksum a mentioned 
in [lCMPv6] . 
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message, set the ACK bit to one. otherwise, set the ACK bit to 
zero. 

- if it is a case of pre-assignment of prefixes, set the Sequence 
Number field to zero, otherwise, set it to the value from the 
previously received PS message. 

- Set the Service field to either the current or updated Service 
band of the RR 

- if the Identifier field is non-zero, Set the Identifier field to 
the same value. Otherwise, set it to the newly arrived Identifier 
value. 

- The Reserved field should be to set to zero. 
7.1.2 Prefix Delegation Option Specification 

- if Addresses could be allocated in a block, use Block Delegation 
Response Option. Set the Prefix Length field to the prefix length 
that is common to all the prefixes in the block. Set the starting 
address of the prefix block (inclusive) in Prefix Address Block 1 
and the ending address of the prefix block (inclusive) in Prefix 
Address Block 2. Set the valid Lifetime field to the applicable 
value. 

- If Addresses could not be allocated in a block, use individual 
Delegation Response Option. Set the Prefix Length field to the 
prefix length of the prefix and load the prefix in the Prefix 
field. Set the valid Lifetime field to the applicable value. 

7.2 Prefix Revoking by a Delegating Router 

A DR can revoke the prefixes that it had delegated using a PS 
message. This SHOULD NOT be piggy-backed with a current delegation 
response and SHOULD be sent only as a standalone message. 

7.2.1 Prefix Revoking Header Specification 

- Set Type to PD_PE_RESPONSE, Code to zero and checksum a mentioned 
in [ICMPV6] . 

- Set the ACK bit to zero, since this is not an acknowledgement. 

- If it is a case of pre-assignment of prefixes, set the Sequence 
Number field to zero. Otherwise, set it to the value from the 
previously received PS message which performed the delegation. 

- Set the Service field to either the current Service band of the RR 

- Set the identifier field to the value of the RR. 

- The Reserved field should be to set to zero. 

7.2.2 Prefix Delegation option Specification 

- If Addresses could be revoked in a block, use Block Delegation 
Response option. Set the Prefix Length field to the prefix length 
that is common to all the prefixes in the block. Set the starting 
address of the prefix block (inclusive) in Prefix Address Block 1 
and the ending address of the prefix block (inclusive) in Prefix 
Address Block 2. Set the valid Lifetime field to all ones 
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- if Addresses could not be revoked in a block, use individual 
Delegation Response Option, set the Prefix Length field to the 
prefix length of the prefix and load the prefix in the Prefix 
field. Set the valid Lifetime field to all ones (Oxf f f f f f f f ) . 



7.3 Prefix Solicitation Message Validation by Delegating Router 
A DR receives PS messages from RRs which require prefixes. 

7.3.1 Prefix Solicitation Header Validation 

- verify if Type is pd_CPE_jiequest, Code is zero and checksum is 
correct. If not, silently ignore the message. 

- If the ACK flag is set, the RR is acknowledging a previous PD 
message, if the ACK flag is not set, the RR is making a fresh 
request. 

- If the Discretion flag is set alongside the ACK flag, ignore the 
message. Otherwise, ensure that all prefixes are available with 
appropriate Valid Lifetimes. If prefixes are not available, 
silently ignore the message. 

- If the Sequence Number field is zero and the Ack flag is not set, 
silently ignore the message. 

- if the Service field is zero, assign a new Service band for the RR. 
If the Service field is different, assign the new Service band if 
it meets the policy guidelines, if any. 

- If the Identifier field is zero, check for SLLA option. If not 
found, silently ignore the message. If found, use it in a 
implementation-dependent hash algorithm to generate a 32-bit 
identifier for the RR. 

- ignore the Reserved bits. 

7.3.2 Prefix Solicitation Options validation 

- if ACK flag is set and there are no options, all the prefixes that 
were allocated in the message with the appropriate Sequence Number 
are acknowledged by the RR. If ACK flag is not set and there are 
no options, check for a case of Pre-assigned prefixes. 

- If Identifier field is non-zero, ignore the SLLA option. 

- For all kinds of prefixes solicited, check if such a prefix is 
in the Free state. If not, ignore the Prefix. 

- if Prefix Length is set to zero in the solicitation message, the 
default prefix value is taken. 

- For all available prefixes, check if Valid Lifetime 1 option is 
zero, if so, ignore the Valid Lifetime 2 option and delegate the 
prefix with Valid Lifetime depending on the service Band of the 
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Customer, ignore the prefix if Ack bit is zero and valid Lifetime 
is all -ones (Oxf f f f f f f f ) . if Ack bit is one and Valid Lifetime 
is all -ones (Oxf f f f f f f f ) , set the entry to Expire in the table and 
ignore the valid Lifetime 2 option. 

- If valid Lifetime lis non-zero and not all -ones, Check Valid 
Lifetime 2 to see minimum and maximum values for Valid Lifetime. 
If such a prefix matches, delegate it with Valid Lifetime based 

on the Service Band of the customer. Otherwise, ignore the prefix. 

- once a prefix is delegated, Mark it as Pending. After receiving the 
Ack, set it to Delegated. 



7.4 Configurable Parameters for Delegating Router 



PDPEMaxRetries The number of retries the DR has to perform 

before it gets an Ack to its PD message. 

PDPEMaxPrefixes Maximum number of prefixes that could be 

delegated by a DR at its next request. It 
depends on the type of service that the RR 
enjoys. 

PDPEDynamicThreshold 

The threshold value which is used to determine 
if a prefix is static or a dynamic prefix. This 
can be used when the DR wishes to allocate for a 
static or a dynamic prefix. 

PDPEDeprecateTimer The value in seconds for which a prefix would 

remain deprecated, when there are 
PDPEDeprecateTimer seconds for the valid 
Lifetime to expire, the RR can start expecting 
renewal requests for the prefix. 

PDPERetransTimer The value in seconds between two retries. 

PDPEExpi reTimer The value in seconds when the DR decides that 

the prefix can be freed after having expired 
earlier. 

PDPEDef aul tPref i xLength 

The default prefix length to be chosen by the PE 
if the RR does not have any preference on the 
prefix length. 

PDPEReplayTimer The value in seconds after a which a DR allows 

an old sequence number to be accepted as a valid 
sequence number and not reject it as a replay. 

8. IANA Considerations 

IANA is requested to assign an option code to the following options 
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from the option-code space for icmpv6 [ICMPv6] . 

option Name value Described in 

PD_CPE_S0LICIT tbd Section 4 

PD_PE_RESPONSE tbd Section 4 



9. Security considerations 

For point to point links, where one trusts that there is 

no man in the middle, or one trusts layer two authentication, 

authentication may not be necessary. 

on other links, Security considerations like man in the middle 
exist. 
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Appendix A : usage of Service Bands & Discretion Flag 

Service Bands can be used for various reasons. A DR can use a Service 
Band to distinguish between various customers. The number of prefixes 
that would be delegated to a RR, the Lifetimes of those prefixes, 
Revoking of prefixes and Renewal of prefixes could be streamlines 
using Service Bands. 

For example, a customer with a certain Service Band could be allowed 
more renewals than a customer with a lower service Band. Service 
Bands serve as an important tool for the DR to apply policy based 
delegation. 

At the time of specifying this mechanism, the DR is eligible to 
define it's own service bands. Further discussions may result in 
well known Service Bands being identified. 

The Discretion bit is aimed to allow complete freedom on the part of 
the DR, provided the RR is okay with it. in cases, where the RR 
wishes to check if this DR has a certain prefix that it requires, it 
can send a PS message with the prefixes and the Discretion bit unset. 
It also helps in cases when the RR is specific about having certain 
Valid Lifetimes for the prefixes that it requires. In such cases, the 
RR can unset the Discretion bit to let the DR know that it should not 
apply it's discretion while delegating the prefixes. 

if the Discretion bit is set, it also allows the DR to exercise its 
discretion on Valid Lifetimes and Block of Prefixes. 

Appendix B : implementation Suggestions on usage of Prefix States 

The Deprecated state can be used as a method to block flood of 
renewal messages. Unless the Prefix passes on to Deprecated State, 
renewal messages would not be entertained and would be silently 
ignored. This could help in preventing a DOS attack using Renewal 
Messages. 

Appendix c : Future Options 

Future options could be added to share other information between 
RRs and DRs. Some of the options that have been considered at the 
time of specifying this mechanism are 

- Synchronizing Global values between RR and DR 
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This would help in the RR and DR knowing information about each 
other. 

- Accounting information Requests from DR to RR 
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If the DR wishes to have accounting information on the usage of 
prefixes, these requests would help in it. 

- current Status of a Prefix from RR to DR 

At times, a RR might want to get details about the prefixes that 
it has been allocated with. It could use this option to query the 
Current State and Status of the prefix. 

- Reservation of a prefix by the RR with the DR 

The RR might want to reserve a prefix with the DR which it would 
start using after a specified amount of time. The Reservation 
Option would facilitate this. 
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